…ests

Neither workers/v2/duckdb.worker.ts's handlers nor
workers/v2/inference.worker.ts's handleInference were exported or
unit-tested against real logic (only webllm.worker.ts had that,
tests/unit/webllmWorkerHandler.test.ts) despite both already being
registered as live WorkerBus v2 pools with zero production callers —
docs/adr/0014-worker-generation-duplication.md's deferred migration
needs these to actually match v1 before any consumer cuts over.

Testing surfaced a real gap: initDuckDb()'s OPFS-unavailable catch
block silently swallowed the failure, unlike v1's out-of-band
OPFS_FALLBACK message that lets the UI warn users their analytics
won't persist. Fixed by threading ctx.emitProgress into initDuckDb()
and emitting an 'opfs-fallback' progress stage from the catch block —
reuses the existing progress channel WebLLM already uses for download
progress, no new message-protocol/schema change needed.

First PR of the ADR-0014 consolidation sprint (5 PRs total, see
.claude/plans/worker-generation-v1-vs-enumerated-fox.md).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

…QL param binding

Three real findings from CodeRabbit's review of #287 (duckdbClient
migration onto WorkerBus v2), all confirmed against current code
before fixing:

1. CRITICAL — params silently dropped (workers/v2/duckdb.worker.ts).
   duckdbClient.send() enqueues {sql, params}, but handleQuery/
   handleExec only read req.sql and called connection.query(sql)
   directly, ignoring params entirely and leaving an unbound-query/
   SQL-injection surface flagged by static analysis. This was already
   live: services/ai/telemetryService.ts's writeToDuckDb() passes real
   bound params ([taskType, backend, modelId, latencyMs, success])
   that were being silently discarded. Fixed via DuckDB-WASM prepared
   statements (connection.prepare(sql) + stmt.query(...params) +
   stmt.close()) when params is non-empty; unchanged direct
   connection.query(sql) otherwise. Needed a narrow structural type
   (PreparableConnection) since tsgo doesn't resolve
   AsyncDuckDBConnection.prepare() through this package's nested
   `export *` chain, despite it being present in the package's own
   .d.ts — same class of tsgo/external-package gap CLAUDE.md already
   documents for the transformers.js path alias.

2. MAJOR — DuckDB pool worker losing its connection on respawn
   (services/duckdb/duckdbClient.ts). The duckdb pool's minWorkers:0
   lets its worker idle-terminate; a freshly spawned replacement
   worker's module state has no `connection` until INIT runs again on
   it, so the next QUERY/EXEC after a respawn failed with "DuckDB not
   initialized". Fixed by transparently re-sending INIT once and
   retrying the original call when send() sees that specific error
   message (bounded to one retry, INIT/SHUTDOWN excluded from the
   check to avoid any recursive loop).

3. MAJOR — terminatePool() had no lifecycle contract
   (packages/worker-bus/src/workerBus.ts +
   services/workerBusManager.ts). Removing a pool didn't settle tasks
   already routed to it — their result promises would await a RESULT
   message from a worker that no longer exists. Fixed by tracking
   task->pool assignment (new taskPools map, set/cleared around
   runTask's pool-acquire phase) and cancelling matching tasks before
   deletion. Separately, ensureDuckDbPool() assumed a non-null bus
   always has every pool, so any call after duckdbClient.terminate()
   would fail with NO_POOL forever; added WorkerBus.hasPool() and a
   re-registration path (duckDbPoolOptions()/reRegisterDuckDbPool(),
   shared with doInitWorkerBus() to avoid option drift between the two
   registration sites).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

…uilds

Root cause of both Vercel deployment failures on this branch/PR chain:
services/ai/localEmbeddingService.ts imports and calls
ensureInferencePool() from workerBusManager.ts, but that function was
never actually added there — only ensureDuckDbPool() was. Vitest never
caught this because localEmbeddingService.test.ts mocks the entire
workerBusManager module (vi.mock(...) replaces it wholesale), so the
real file's missing export was invisible to that suite. tsgo's
typecheck also passed clean locally for reasons still unclear (worth
a follow-up look), but rolldown's stricter static bundling in the
actual `pnpm run build:edge` (Vercel's exact build command) correctly
failed hard with [MISSING_EXPORT] — reproduced locally with
`NODE_OPTIONS=--max-old-space-size=3072 pnpm run build:edge`, which is
what actually surfaced this.

Added ensureInferencePool(), mirroring ensureDuckDbPool()'s shape
(decoupled from enableWorkerBusV2, re-registers the pool if it was
removed via terminatePool() while the bus stays alive). Refactored
doInitWorkerBus()'s inline 'inference' pool registration to share the
same inferencePoolOptions() the new function uses, avoiding the same
kind of drift the duckdb pool options already guard against.

New tests in workerBusManager.test.ts import the *real* module (only
@domain/worker-bus is mocked) — this exact suite would have caught the
missing export immediately, unlike the fully-mocked consumer-side
test. Verified fixed via a full local `pnpm run build:edge`
reproduction of Vercel's exact build command (previously failed with
[MISSING_EXPORT], now builds clean).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

…ing-migration

# Conflicts:
#	packages/worker-bus/tests/workerBus.test.ts
#	services/duckdb/duckdbClient.ts
#	services/workerBusManager.ts
#	tests/unit/duckdbClient.test.ts
#	tests/unit/inferenceWorkerHandlerV2.test.ts
#	tests/unit/workerBusManager.test.ts
#	workers/v2/duckdb.worker.ts

ensureDuckDbPool() and ensureInferencePool() could reject after _bus was
already live because their re-registration helpers awaited a lazy import and
called registerPool() without a catch, breaking the documented "null only if
init failed" contract. Wrap both paths so a failed re-add logs instead of
propagating, and add a maxWorkers:2 assertion to the inference re-registration
test so the pool cap regression would be caught.

Addresses CodeRabbit review comments on PR #288.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

The prior CodeRabbit fix (8a63b7c) added try/catch guards in
ensureDuckDbPool()/ensureInferencePool() so a pool re-registration failure
logs instead of propagating, but no test exercised the catch path — Codecov
flagged 4 missing lines (83.33% patch coverage). Adds one test per function
that forces registerPool() to throw and asserts the live bus is still
returned and the failure is logged via services/logger.ts.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

…de-diff-range review

Addresses CodeRabbit's 2 still-valid findings on PR #288: the logger mock
(why it's isolated from the real StructuredLogger) and the maxWorkers:2
regression assertion (why 2, not just what). The other 3 flagged spots
(reRegisterInferencePool, the inference registry.register block, and the
mockLogError.mockClear() line) mirror already-uncommented sibling code in
the same files (reRegisterDuckDbPool, the duckdb registry.register block,
6 other .mockClear() calls) — commenting only the new instance would be
less consistent, not more, so those are left as-is.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>